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Technical Field 

5 This invention relates in general to techniques 

generally known as w internetworking" . 

In general terms, the basic objective of 
internetworking is the co-operation and interoperability of 
elementary systems (seen as "black boxes") to create a 

10 macrosystem capable of presenting the characteristics of 
the constituent systems with the addition of a number of 
advantages . 
Background Art 

Firstly, when two or more different administrative 

15 entities reach an internetworking agreement they extend 
(within contractual limits) their respective catchment 
areas without additional expenses for wiring or structural 
purposes. It is reasonable to think that the service 
quality perceived by the final user may be increased due to 

20 the larger size of the reference network. 

In the specific case of the so-called Content Delivery 
Networks, or CDNs, additional contents and diversification 
is also provided. 

For its very nature, an internetworking solution 

25 requires the presence of interface components which, on 
elementary system (i.e. single CDN) side have a complete 
overview of the evolution of the static and dynamic 
characteristics and which on the "rest of the world" side 
(i.e. on the side of the other internetworking networks, 

30 that is on peer side) have only the comprehensive 
information needed to establish profitable intersystem 
communication. The term "profitable" here means efficient, 
safe and reliable being provided with the mechanisms that 
this type of solution entails. 
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Regulations concerning the matter are currently being 
drawn up, as documented, for example, by the following 
draft standards published by IETF (Internet Engineering 
Task Force) which can be retrieved from the organisation's 
5 web site, namely: 

"A Model for CDN Peering", by M . Day, B. Cain, G. 
Tomlinson and P. Rzewski, May 2 001; 

"Content Internetworking Architectural Overview", by M. 
Green, B. Cain, G. Tomlinson, S. Thomas e P. Rzewski, March 
10 2001; 

"Known Mechanisms for Content Internetworking", by F. 
Douglis, I. Chaudhri and P. Rzewski, November 2 001. 

The interface components are called Content 
Internetworking Gateways or CIGs. CIGs have a complete 
15 overview of the environment within their respective CDN and 
perceive the data related to remote environments through 
protocols for. exchanging data, called "advertisements" . 

From an abstract point of view, a CIG must route 
requests (i.e. perform request -routing functions), on the 

2 0 basis of all data from the pre-existing infra-CDN modules 

(distribution system and monitoring system) and equivalent 
remote devices. 

According to the aforesaid standards, the CIG routes a 
client's content requests. 
25 Specifically, having received a -request for a certain 

content and having verified that the content is available 
in its respective CDN, the CIG sends the corresponding 
required content cache ID to the client. The concerned CIG 
is consequently capable of routing the request, also when 

3 0 the content is hosted in the cache of another CDN. 

In this situation, when several CDN networks are 
internetworking, the CIGs perform address resolution and 
content request -routing functions, which on internet level 
are remitted to other network members, particularly by 



i 



WO 03/090423 PCT/EP03/04059 

3 

involving the so-called DNS (Directory Name Service or 
Domain Name Server) . 

This leads to splitting/duplication of functions which 
causes several problems. The problems are related, among 
5 other, to the need of ensuring correct synchronisation 
between CIGs and devices in the Internet and to the fact 
that the request from a certain client is processed 
differently according to whether the request involves the 
CDN level or not. 
10 disclosure of the Invention 

The object of the invention is to overcome these 
shortcomings . 

The object is obtained according to the invention 
thanks to a procedure whose characteristics are recited in 
15 the annexed claims. The invention also relates to a 
corresponding system of internetworking CDN networks and a 
respective interface or CIG component. 
Brief Description of Drawings 

The invention will now be described, by way of example 

2 0 only, with reference to the accompanying drawings wherein: 

- Figure 1 generally illustrates the internetworking 
organisation criteria of two CDN networks, 

- Figure 2 generally illustrates the structures of a 
Content Internetworking Gateway, or CIG, according to the 

25 invention, 

- Figures 3 and 4 illustrate different infra-CDN and 
inter-CDN request -routing methods, 

- Figures 5 to 7 illustrate the typical CIG context 
diagrams at various levels detail according to the 

3 0 invention, 

- Figure 8 shows the finite state automaton of a 
corresponding CIG, 

- Figure 9 is a time diagram showing the opening of a 
corresponding session, and 
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- Figures 10 to 13 illustrate the format of the 
various messages exchanged by a CIG according to the 
invention. 

Best mode for Carrying Out the Invention 

5 The diagram in figure 1 illustrates the collocation of 

two Content Internetworking Gateways (hereinafter called 
CIG for short) intended to permit exchange of 
w advertisement" data in the context of a set formed by two 
Content Delivery Networks CDN1 and CDN2 in combination with 

10 an Origin Server (OS) each. 

Each CDN shown here consists of a respective 
administrative domain with a Directory Name Service or 
Domain Name Server (DNS for short) , management centre, 
cache memories and connections to client function 

15 terminals . 

Figure 1 shows the role of the CIGs in the 
internetworking process. One of the specific 
characteristics of a CIG is the degree (or level) of 
integration, as a parameter, respect to the modules which 
20 are already present and operational within a CDN. 

The higher or lower efficiency of the respective 
interface functions can be assessed according to this 
parameter. 

Figure 2 briefly illustrates the interface components 
2 5 which form a CIG according to the invention in the 
currently preferred form of embodiment. 

Specifically, the concerned CIG consists of: 

- a first interface module, called Request -Routing 
Interface or RRI , which exchanges data with the remote CIGs 

30 according to CNAP protocol specifications (described in 
detail in the description that follows) , 

- a second interface module, called DNS Interface or 
DNSI, which interfaces with the DNS of the CDN to which the 
CIG belongs, 
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a third interface module, called Dist ribut ion 
Information Interface, or DII, which retrieves data on the 
availability of contents from the distribution system of 
the CDN to which the CIG belongs, 
5 - a forth interface module, called Monitoring 

Information Interface, or Mil, which interacts with the 
monitoring system, and finally 

- a central module, called Request-Routing Process, or 
RRP, which collects and processes the information received 
10 to implement the request -routing function: the latter 
module is the CIG core. 

It is noted that the aforesaid architecture, although 
preferred, is not absolutely imperative or binding, at 
least as concerns the presence of the third or fourth 
15 interface module described above. 

Further reference to the CNAP protocol may be found in 
"Content Network Advertisement Protocol (CNAP) " by B. Cain, 
O. Spatscheck, L . Amini, A. Barbir, M. May and D. Kaplan, 
November 2001, which may also be retrieved from the IETF 
20 web site. 

Briefly, the CIG consists of a central module which is 
the "brain" of the device and a certain number of interface 
modules between the CIG and the pre-existing 
infrastructure . 

25 The described request -routing technique solution 

refers to modules implementing DNS technology. 

Consequently, two likely internetworking scenarios may 
be hypothesised and illustrated in an event trace diagram. 
Figure 3 shows a classical content routing scenario, 
30 so to speak, the term herein indicating a standard routing 
process in a CDN (implementing DNS technology) in which DNS 
table updating is delegated to the CIG by means of the DNSI 
module . 

Extending the example to an actual internetworking 
35 case is easy with this procedure. 
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The labels and the directions of the arrows in the 
figures help to understand the real sequence of events: a 
user makes a content request to the DNS system which works 
in standard mode. The DNS responds with the best surrogate 
5 IP address according to the routing policies applied at the 
time. The CIG periodically updates the DNS tables, 
according to the information received from the distribution 
and monitoring system; note that in this first case, the 
system is "isolated" , so to speak. 

10 Conversely, in the situation in figure 4, the selected 

surrogate servers belong to another administrative domain, 
i.e. CDN. The dynamics appears essentially similar to the 
example above. In this case, as above, the client queries 
the DNS which replies with the best surrogate server IP 

15 address. The difference is in the data retrieving and 
updating method. The bi-directional arrows in the central 
section indicate the periodical exchange of routing data 
between entities on the same hierarchic level (peers), i.e. 
the CIGs, according to the conventions and the 

20 specifications of the CNAP protocol. This type of data is 
similar to infra-CDN data, and used by a CIG to update the 
DNS tables on the basis of a wider range of data with 
respect to that which occurs in known architectures. 

The roles of the modules which form a CIG operating 

25 according to the invention will now be described with 
reference to the diagram indicated by the acronym DFD (Data 
Flow Diagram) . 

The higher level approach consists in the use of a so- 
called context diagram. The diagram represents the 
3 0 interactions between the whole CIG and the "outside world" . 
As shown, the CIG appears as a single entity capable of 
interacting with the rest of the world. 

The CIG routes requests according to the information 
from the other entities with which it communicates. More in 
35 detail, it receives data from peers, from the distribution 
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system and the local monitoring system. After processing, 
the data, the DNS tables and the log file archives are 
updated. 

At this point, the request -routing system can be 
5 observed closer, by splitting into . subsystems and 
representing the functions on different levels of detail. 
Two subsequent expansions are illustrated in figure 6 and 
figure 7, respectively. 

Specifically, the interface processes clearly appear 
10 in figure 6, corresponding to a first level of detail: 
these are "buffer" modules which communicate with the 
central process on one side and with the outside world on 
the other. 

Figure 7, on the other hand, illustrates the functions 

15 of the RRP core. The RRP receives data from the rest of the 
world and transmits them via the interfaces, extracts 
useful information on cache and/or content state, evaluates 
the need to update and consequently modifies its own 
database, the DNS tables and the log file archives. 

20 Finally, if required, it sends the message to its peers, 
through the request -routing interface RRI . 

The request -routing interface RRI interfaces with the 
rest of the world. From this point of view, it is the most 
important module in the internetworking procedure, because 

25 it is directly implied in inter-CDN communication; as 
mentioned above, this communication is carried out 
according to the conventions of the CNAP protocol which was 
designed for this purpose. 

This module is responsible for translating the 

30 messages from CNAP (inter-CDN) format to a format which can 
be understood by the CIG (infra-CDN) central process, or 
RRP. The CNAP protocol requires initial specifications (and 
periodical updating) or a set of data, which are static so 
to speak, referred to the internetworking system topology 
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characteristics. For example, the following may be 
requested: 

- the local CNAS ID (i.e. the CDN to which the 
concerned CIG belongs) ; 

5 - the IP address of the local CIG computer; 

the CNAS IDs of remote interconnected systems 
(peers) with which internetworking will be established; 

the IP addresses of the remote CIG computers 
corresponding to the systems mentioned in the point above; 
10 - the inter-CNAS level of confidences; and 

- a numeric coefficient indicating the "weight" in 
static conditions of each connection (practically similar 
to the geographical distance of the connection) . 

The protocol offers the possibility of diversifying 
15 the contractual internetworking relations with the 
introduction of level of confidences. In other words, 
before disseminating information on availability of a 
content to a remote CIG, the local CIG verifies whether the 
CIG is enabled to received the information according to the 
2 0 stipulated contact. 

The CNAP connections, as required by the IETF for 
internetworking protocols, implement a reliable connection- 
oriented protocol on transportation level: for example, TCP 
(Transmission Control Protocol) , currently employed in 

2 5 Internet contexts, may be used. 

The logical operations needed to establish a CNAP 
session are shown below. 

This is carried out with specific reference to the 
finite state automaton diagram of the CIG as illustrated in 

3 0 figure 8. 

During the initial state of the CIG, called IDLE, 
there is no CNAP session and no entity has intervened to 
change this situation. When the CIG intends to establish a 
CNAP session with a remote CIG, it sends an OPEN message 
3 5 and goes to OPENSENT state. 
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The remote, also initially in IDLE state, receives a 
request to open a CNAP session. It replies with a KEEPALIVE 
message and goes to 0 PENCONF I RM state. 
Two cases may occur. 
5 In the first case, the original CIG receives the 

KEEPALIVE message within a predetermined lapse of time: in 
this case, it goes to READY state and waits to send 
advertisement messages (i.e. messages carrying useful data, 
not only metadata, as initialisation messages) . 

10 In the second case, the predetermined time-out expires 

before the original CIG receives the expected KEEPALIVE 
message: in this case, it returns to IDLE state and the 
communication attempt fails. In general, a NOTIFY message 
will inform the parties of the anomaly. 

15 The remote CIG, having sent the following KEEPALIVE 

message, also goes to READY state and listens out for 
advertisement messages to be received. 

The reception of a NOTIFY message, makes the CIG go to 
IDLE state. As may easily be assumed from the description 

20 above, the CNAP connection is active and efficient if both 
involved CIG are in READY state. 

Figure 9 shows the sequences of state which 
characterise opening of a CNAP session and highlight the 
evolution of events in time. 

25 The messages exchanged by the RRP core and the 

request -routing interface RRI may have the format shown in 
figure 10. 

The meaning of the message fields is shown below: 
URL: is the URL identifying the content of the 
3 0 message; 

IP: is the IP address of the cache which distributes 
the contents; 

CNAS ID: is the ID of the CDN to which the cache 
belongs; 

35 CACHE STATE: is the state of the cache; 
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CONTENT STATE: is the state of the content in the 
cache ; 

TTL: is the life time of the routing data. 

The monitoring interface Mil is the module which 
5 implements the interface between the RRP core and the local 
monitoring system, i.e. referred to the CDN to which the 
CIG belongs. The data which must be transferred to the RRP 
refer to the CDN cache state; the term "state" here 
indicates quantification of the available resources. 
10 In this perspective, the format of a message from the 

monitoring interface Mil may assume the appearance shown in 
figure 11. 

The message has five fields whose meaning is 
illustrated below: 
15 IP: the IP address of the cache to which the message 

refers ; 

CPU: percentage of CPU used by the cache; 

MEM: percentage of RAM used by the cache; 

DISC: percentage of disc used by the cache; 
20 USERS.: percentage of the number of connected users (in 

relation to the maximum service capacity of the concerned 
cache) . 

The parameters are classical performance indicators 
which are used to assess the conditions of use of the 
25 cache. Messages of this type are passed to the RRP at 
regular intervals of time. 

The DII distribution interface is the interface module 
between the distribution system and the RRP core of the 
CIG. The DII interface collects information on the presence 
3 0 and availability of the cache contents. Figure 12 shows the 
format of a possible message of this type. 

The meaning of the fields is shown below: 

URL: is the URL identifying the content to which the 
message refers; 
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CACHE: is the list of IP addresses of the caches in 
which the content is available; 

LEVEL OF CONFIDENCE: is the level of confidence of the 
content ; 

5 CONTENT AVAILABILITY: indicates whether the content is 

available or not; 

CACHE STATE: is the status of the cache; 
TTL: indicates the life time of the routing data. 
Three levels of confidence can be associated to the 
10 contents, i.e.: 

low - contents can be exchanged with all 
interconnected CDNs ; 

medium - contents can be exchanged only with CDNs 
which have subscribed a MEDIUM level confidence agreement 
15 with the CDN that owns the content; and 

high - contents can be exchanged only with CDNs which 
have subscribed a HIGH level confidence agreement with the 
CDN that owns the content. 

The DNS interface, indicated by DNSI, is the interface 
20 module which must communicate with the DNS server, to 
update the tables. A possible format of the message useful 
for this purpose is shown in figure 13. 

The meaning of the respective fields is: 
OP: indicates the operation to be carried out on the 
25 DNS table (two operations are available, "add" and 
"delete") ; 

REG TYPE: indicates the type of register; 

DOMAIN NAME: indicates the name of the domain to which 
the message refers; 
30 IP: is the address of the best cache IP address to 

serve the domain above; 

TTL: is the life time of the register. 

Alternatively, the DOMAIN NAME field may contain the 
entire URL of the content to which the message refers. In 
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this way, the DNS can directly identify the best cache for 
content delivery. 

The request -routing module RRP is, as mentioned above, 
the core of the system. It is responsible for processing 
the data received from the aforesaid interface modules, 
updating the DNS tables if required via the DNSI interface 
and forwarding the data to the other CIGs through the RRI 
interface . 

It is also responsible for managing the log file archive. 
Given the need to enable the respective DNS to perform the 
address resolution function (to make content delivery 
factually * transparent" with respect to the presence of a 
set of internetworking CDN networks) , the RRP core must 
have a data structure which will store the states of the 
local CDN and the remote CDNs . The data structure must 
collect and organise the data referred to contents 
available in the internetworking system context and to the 
caches capable of providing the contents. Data structure 
definition is periodically updated by the RRP module, in a 
different way according to the type of message which 
prompted the updating process on a case-by-case basis. 

Naturally, numerous changes can be implemented to the 
construction and embodiments of the invention herein 
envisaged without departing from the scope of the present 
invention, as defined by the following claims. 



